==========
psion/opl #1720, from psipple, 197 chars, Dec 29 20:45 94
----------
Accessing Print Setup from OPL
Can someone lt me know if there's an easy way to gain access to the print 
setup dialog (as used in DATA, WORD, ETC) for use within an OPL proc?

TIA,

Pete


==========
psion/opl #1721, from dw2, 2662 chars, Dec 30 8:27 94
Comment to 1720.
----------
Print setup from Opl - try the following:

PROC psetup:
  while 1
    send(peekw($38),25)
  endwh
ENDP

This uses one of the methods of the "gate" class (handle always written 
to $38).  These extra methods only exist on the S3a, not on the S3 
classic.

Then to actually print, consider something like the following example 
program:

PROC test:
  global orec%(300)
  global styles%(10)
  global msg$(10,40)
  msg$(1)="First line of the Opl printout"
  msg$(2)="This line is bold"
  msg$(3)="Three"
  msg$(4)="Four"
  msg$(5)="Five"
  msg$(6)=""
  msg$(7)=""
  msg$(8)="Eight"
  msg$(9)="Nine..."
  msg$(10)="That's all for now folks"
  setstys:
  while 1
    send(peekw($38),25)
    settext:
    actions:
  endwh
ENDP

PROC setstys:
  styles%(1)=6  rem bold italic
  styles%(2)=2  rem bold
  styles%(3)=4  rem italic
  styles%(10)=1 rem underlined
ENDP

PROC settext:
  local i%
  i%=1
  do
    dInit "Define line "+num$(i%,2)
    dEdit msg$(i%),"Text",40
    dialog
    i%=i%+1
  until i%>10
ENDP

PROC actions:
  setorec:
  preview:
ENDP

PROC setorec:
  local i%,j%
  i%=1
  while i%<=300
    j%=1
    while j%<=10
      orec%(i%)=styles%(j%)
      orec%(i%+1)=len(msg$(j%))
      orec%(i%+2)=addr(msg$(j%))+1
      i%=i%+3
      j%=j%+1
    endwh
  endwh
ENDP

PROC preview:
  send(peekw($38),24,#1,#100,orec%(1))
ENDP

(You'll have to have set the Printer Device beforehand, from the System 
Screen.  If you print to the wrong device, or eg print to a parallel 
printer without the parallel port being plugged in, there will be no 
error notification.)

Actually, this program runs the Print Preview system before offering the 
Print menu (inside the Print Preview system).  To get access to Printing 
without having the Print Preview first, in

  send(peekw($38),24,#1,#100,orec%(1))

change the #1 to #0 and all should be well.

Also in this line, the #100 refers to the fact that, in the buffer 
specified by the final parameter, there are 100 "lines" of data to be 
printed.  Each such "line" consists, as you can see, of three integers:

* the first defines the style of the line
* the second defines the number of characters in it
* the third gives the address of where these characters can be found.

You'll see that all this is fairly crude - it provides a fairly 
unsatisfactory back-door mechanism to the ROM print subsystem.  You have 
to assemble all the "print data" in memory beforehand - which isn't 
practical for most realistic programs, I think.  This is one place where 
Hwif makes a much better job than Opl.

Regards, DavidW


==========
psion/opl #1722, from psipple, 108 chars, Jan 1 14:25 95
Comment to 1721.
----------
Many thanks for your very comprehensive reply. Your help with this is 
appreciated!

Regards,

Pete


==========
psion/opl #1783, from cporteous, 236 chars, Jan 24 23:59 95
Comment to 1721.
----------
David,
I have used the code in this message in a routine of mine
Everthing works fine when #0 is used for direct printing
but when using #1, after the print preview I get a
panic 55 ........ any ideas?

Regards,
        Colin


==========
psion/opl #1796, from dw2, 347 chars, Feb 1 20:13 95
Comment to 1783.
----------
Sorry for the delay in answering.  I'm afraid anyone who tries to use 
this code is on their own.  I posted the original more as a curiosity 
item rather than anything else, though I know that various people have 
incorporated this idea into fairly substantial Opl programs without 
experiencing the panic 55 you report.

Regards, DavidW


==========
psion/opl #1797, from cporteous, 315 chars, Feb 3 15:58 95
Comment to 1796.
----------
David,
        I quite understand if you don't have time to investigate this but 
if you add the following to your code then you should get a panic.
(using #1 for print preview)

>PROC actions:
>  setorec:
>  preview:
   minit
   mcard"anything","anything",%a
   menu
>ENDP

Regards,
        Colin


==========
psion/opl #1798, from dw2, 1645 chars, Feb 5 22:54 95
Comment to 1797.
----------
I understand the problem now, and I've got a fix.

The fix is to call the following routine after coming out of the call to 
preview:

PROC tidycom:
  local wws%,com%
  wws%=peekw($12)
  com%=peekw(wws%+$1c)
  if com%
    send(com%,0)
    pokew wws%+$1c,0
  endif
ENDP

What's going wrong is that the print preview subsystem is leaving its 
"command manager" (menu-bar handler) installed.  Opl programs don't have 
a command manager, and the test for this is to see if the word at 
(wws%+$1c) is non-zero.  Since this is wrongly left non-zero after the 
print preview subsystem exits, all bets are off as to what happens next.

The above code fragment
1. checks whether the command manager handler is non-zero
2. if so, sends a "destroy" message (message number 0) to it
3. and then nulls the reference to it.

The fix is harmless when called just for the "pure" printing case - since 
there's no com% in this case.

I suppose it's instructive to note why the print preview subsystem didn't 
remove its own command manager in this case.  It's because it had 
recorded the handle of the previous command manager, and then, in the 
destroy code for the preview subsystem, tested the stored value of the 
previous command manager to see if it was non-zero.  This test is 
*correct* in most cases, since it ensures that, in cases where the 
preview system fails to fully initialise (eg due to OOM part-way 
through), it doesn't put back a value it never managed to record in the 
first place.  But the test fails to distinguish never recording the 
value, and recording the null value :-(

Regards, DavidW